Outputs shouldn't be committed to git. It's otherwise very hard to see if the code changed ore only the outputs.

Thank you for the feedback. The reason for having the outputs in the notebooks is that we are using the notebooks as documentation, so we want to have the user be able to see the output without necessarily running the notebooks. But this is most relevant for the documentation itself, which just includes the notebooks and thus requires the outputs to be there. Do you know if it is possible to have the notebooks without output in the repository, and have the documentation CI action run each cell of each notebook before compiling the documentation and putting it online?

This might be helpful:
https://mg.readthedocs.io/git-jupyter.html

Thanks for the input here.
This doesn't quite address our workflow with the documentation, so I'd like
to request that we move on from this and leave it be for now.
Thanks,
Chris

@ctralie, I understand your perspective. However, for PR reviews, navigating through binaries takes work. Perhaps something like ReviewNB could be a solution? Just a thought.

Thanks for the quick response. I'm curious why you'd look at the binaries directly though. Why not just look at the notebooks themselves, since github renders them?

(This tool does look nice though @raphaelreinauer. I'm just wondering if, in the interest of time, and in the interest of keeping the toolchain simpler, we can punt this issue for now)

This is purely a personal preference (see the Review channel), so please consider it a suggestion to add in the future.

Reviewing a PR, I look at change logs to determine the modifications. The diff in the Jupyter Notebook has both code changes and binaries. However, the binary changes can often overshadow the code modifications, making the PR challenging to review.

Another drawback of committing binaries (which could even change often like plots in Jupyter Notebooks) is that the repository size increases significantly as these files remain in the git history.

Yes, understood, and agreed that it is a pain. I do wish that matplotlib saved svgs instead of pngs where possible in notebooks. But thank you for your flexibility here